E-mail is widely used today and its rapid growth is expected to continue. Over 70 million people use e-mail, sending over 200 million messages daily. Usage is expected to grow by 50% this year, with rapid growth projected for the foreseeable future
However, despite e-mail's growing popularity, current e-mail systems have various drawbacks. These include the fact that e-mail systems are hard to use (particularly for non-technical users), that users are often plagued with excessive junk e-mail, and others drawbacks which will be described below.
The interface problems exist in part because the prior art for storing and displaying messages has evolved in a way that prevents users from readily monitoring key correspondence relationships. This prior art is based on a “message-centric” e-mail paradigm for storing e-mail and communicating information about e-mail to users.
By way of background, E-mail systems are generally either “client-server-based” or “host-based.” In client-server systems messages are forwarded to the server, which stores them until the client logs in and downloads them for use and storage on the client (often the server continues to store messages after sending them to the client). In these systems most of the processing takes place on the client, with the server acting as a “store and forward” agent. Examples of client-server-based systems include typical Internet e-mail provided by Internet Service Providers (or “ISP's”), who use free server softwares such as Sendmail, or proprietary server softwares such as CC-Mail or Microsoft Exchange. Their customers handle their mail using client softwares such as Eudora, or the mail readers packaged with Web browsers such as Netscape Navigator or Microsoft Internet Explorer.
In host-based e-mail systems, on the other hand, messages are stored and processed on the server rather than the client. Examples of host-based systems include (1) main-frame e-mail systems (where users connect using “dumb terminals”), (2) private dial-in networks such as America On-line or Compuserve, and (3) Web-browser-based e-mail systems such as HotMail and Yahoo Mail.
The most widely used e-mail protocols today are POP3 and SMTP. POP3 (“Post Office Protocol 3”, as specified in RFC 1725) is an interface standard designed to facilitate mail management locally on the user's e-mail device. Any POP3-compliant client can receive e-mail through a POP3-compliant e-mail server. (Note: a recent interface protocol, IMAP4-RFC 1730, is similar to POP3 except that it gives the client the option of sharing additional functionality with the server.) Likewise, SMTP (Simple Mail Transfer Protocol, as specified in RFC 821) is an interface used by e-mail servers to exchange messages with other servers. In order to exchange mail over the Internet, servers in both client-server and host-based e-mail systems must be SMTP-compliant.
POP3 and SMTP-based e-mail softwares create, send, and store e-mail in a standard format that does not lend itself to certain functions (that format is specified in RFC 822). These standard e-mail messages are self-contained strings of text, delimited into several standardized fields. Key fields in the messages text string include “header” information (e.g. sender's e-mail address, recipients' e-mail addresses, date/time sent, topic, etc.), and message “body”. Other fields can be appended, but are principally useful only if sender's or receiver's e-mail system can recognize and use them.
These e-mail softwares store and let the user view these messages in a standard way, using designated files (also called “mailboxes” or “folders”). The default files are typically an “Inbox” and an “Outbox.” When a user sends a message the software typically creates a message text string which it appends to the sender's “Out” file, then transmits the string over the network to the receiver's e-mail system, where the text string is appended to sender's “In” file. Users can create additional files (or “folders”), and can then move messages from the “In” or “Out” files to a new file, but this process typically requires manual effort or programming on the user's part.
In prior art systems it is hard to organize, find, and view useful information about one's correspondences. For example, end users can sort or view messages in only one file at a time (e.g. either the “In”-file or “Out”-file, but not both). Further, within a single file users can sort messages only by using a message field contained in the message itself (e.g. by date, topic, or sender's e-mail address). Users cannot reliably or readily view information pertaining to correspondence with a single correspondent, which information is usually contained in two or more files. For example, users cannot see summarized, compiled information about their correspondence history with any one correspondent, nor can they readily view a chronological correspondence sequence of incoming and outgoing mail between themselves and a specific correspondent. Further, sorting mail by sender e-mail address does not consistently link messages to correspondents, because the sender and receiver address fields allow many different text formats for messages sent to the same e-mail address.
Another problem with prior art systems is that they don't manage e-mail address lists well. Just as with handling of e-mail messages, the prior art handles e-mail address lists as flat files with no intelligent linking either to other e-mail address lists or to messages. Also, prior art e-mail address lists must be painstakingly created and managed by the user, rather than being automatically created based on correspondence.
The proliferation of junk e-mail is another problem with the prior art. Junk e-mail—often called “spam”—has lately become so pervasive that a Wall Street Journal article recently opined that spamming “has no foolproof solutions.” Unfortunately, it is impossible to prevent spam by excluding messages from offending e-mailers, because spammers can easily fake their sender e-mail address. The prior art attempted to deal with spam by letting users create e-mail filters in their local e-mail system. Such a filter sorts incoming e-mail for the recipient into categories determined by the user. The filter simply scans each e-mail message as it reaches the recipient and determines what category it should be placed into. One category is, of course, “discard.” Messages which the filter places in that category are automatically discarded. However, these filters have two disadvantages. First, they are hard to create, and consequently most e-mail user's don't bother to use them. Second, filters often filter out the good mail with the bad. For example, an employee survey sent by e-mail may request the user to indicate his or her sex.
The “message filtering technique” in U.S. Pat. No. 5,619,648 to Canale et. al. Apr. 8, 1997, attempted to reduce junk e-mail. However, it offered an entirely different type of solution than the Invention. U.S. Pat. No. 5,619,648 relied on inserting additional information into the standard flat message file. It further required that all third-party users also use its invention, so that patent's application would only apply within closed loops of users.
Another frustration with the prior art is that it doesn't make it easy to own and use multiple e-mail addresses. Many current e-mail users have multiple e-mail addresses, but find it difficult to access them at the same time from a single access device.
Various problems plague organizational users of prior art e-mail systems. One problem is that these systems are hard to set up, and it is hard for users to easily link to other users within the organization.
Another problem with the prior art that plagues organizations is that the prior art consumes excessive computer storage space. This happens in two ways. First, prior art systems store each message on multiple computers. For example, if a user sends a message to one recipient, that message is stored in two to four places (e.g., in client-server systems, the message is stored on sender's client computer, recipient's client computer, and often on both sender's and receiver's server; in host-based systems, the server stores the message in a file for the sender and again in a file for the receiver). Further if a user addresses a message to ten people, then as many as 22 identical copies of that message may reside on the clients and servers of the sender and his addressees!
The second storage problem with the prior art happens when a user wants to file a message under more than one topic. The prior art does this by filing a copy of the message in each file (or folder) selected by the user. If a prior art user wants to store a message under ten topics, then ten copies of the message will be stored (and in the more recent IMAP4 systems as many as 20 copies of the message will be stored—10 on the client and 10 on the server!).
The problems with the prior art exist because since the time of e-mail's development in the 1960's and early 1970's, e-mail has been based on the currently outdated “flat-file” database technology. Flat-file databases, also called also “non-relational” databases, store information as a simple series of “records”, each containing identical “fields” of information (like subsequent rows a spreadsheet, each containing one field of information for each column of the spreadsheet). E-mail messages were structured as flat-file records—self-contained strings of text, delimited into various standardized fields. Key fields in each message's text string included “header” information (e.g. sender's e-mail address, recipient's e-mail address, date/time sent, topic, etc.), and message. Other fields could be appended, but were principally useful only if both the sender's and receiver's e-mail system could recognize and use them.
Prior art e-mail systems store, manage, and display e-mail messages in limited ways dictated by flat-file database architecture. These systems typically file e-mail messages two or more designated flat files (also called “mailboxes” or “folders”). A file contains a series of messages, each of which is analogous to a record, analogous to a “row” in a table or spreadsheet (as described above). The default files are typically “Inbox,” and “Outbox,” files. For example, when a user sends a message, his system typically creates a single string of text containing all the fields in the message, and appends this string to the user's “Out” file. The system then transmits the string over the network to the recipient's e-mail system, where the text string is appended to the recipient's “In” file. Consequently, each user's In-box and Outbox grows longer and longer until the user does something with a message. Users can solve this problem by creating additional files (or “folders”), and can move messages from one folder to another. However, this approach takes thought and effort from the user.
In summary, some of the disadvantages of the prior art are:                1. It does not organize e-mail automatically—instead requires users to organize their e-mail manually; Inboxes and Outboxes grow large and unwieldy because messages are not automatically filed;        2. Hard to see on a single screen the chronological correspondence to and from a given correspondent;        3. Users cannot view on a single screen consolidated information about their correspondence history with multiple correspondents;        4. Hard to remember or find correspondents' e-mail addresses;        5. Doesn't remind users about key information triggers, such as whether the last correspondence with a party was incoming or outgoing, and which correspondences have lapsed.        6. Hard to find past messages;        7. Hard to view groups of past messages in meaningful ways;        8. Users can view messages from only one folder at a time;        9. Time consuming to set up, maintain, and use multiple e-mail address lists;        10. Hard to identify or screen junk e-mail;        11. Impractical to change one's e-mail address;        12. Problematic for an e-mail user to own and manage more than one e-mail address;        13. Users who own multiple e-mail addresses find it hard to move selected contacts and their related correspondence history from one e-mail address to another;        14. Hard to share access to a single e-mail address with others;        15. Hard for organizations to instantly set up an e-mail network for their constituents;        16. Hard for organizations to set up and maintain a single or multiple e-mail address lists for their constituents;        17. Hard for organizations to regulate access to organizational e-mail address lists.        18. Uses excess network storage space because duplicate copies of each message must be stored in multiple network locations;        19. Uses excess storage space on user's own computer, because duplicate copies of messages must be stored for each folder in which a message is filed;        
In summary, the prior art provided a standard flat-file interface which has made it easier to write e-mail programs, but not easier to use them. Problems with prior art e-mail systems include the following: they are hard to use, don't manage messages in optimal ways, fail to manage e-mail addresses well, suffer from excess junk e-mail, make it difficult to manage multiple mailboxes, and are inconvenient for organizations to set up and maintain.